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Optimizing Client Code through Automated Server 

Specialization 

BACKGROUND OF THE INVENTION 

1. Field of the Invention, 

[0001] This invention relates to improvements in end- 

to-end communication between a client and a server. More par- 
ticularly, this invention relates to apparatus and methods for 
minimizing the resources used by a resource-constrained client, 
when accessing services provided by a server. 

2, Description of the Related Art. 

[0002] The meanings of acronyms and certain terminology 

used herein are given in Table 1. The terms Sun, Sun Microsys- 
tems, the Sun logo, Java, J2EE, J2ME, and J2SE are trademarks 
or registered trademarks of Sun Microsystems, Inc., in the 
United States of America and other countries. All other company 
and product names may be trademarks of their respective compa- 
nies . 



Table 1 



API 


Application Programming Interface 


HTTP 


Hypertext transfer protocol 


J2EE 


Java 2 Enterprise Edition 


J2ME 


Java 2 Micro Edition 


J2SE 


Java 2 Standard Edition 


MIDP 


Mobile information device profile 


SOAP 


Simple Object Access Protocol 


WSDL 


Web Service Description Language 


XML 


Extended Markup Language 



[0003] When developing end-to-end applications for thin 

clients, such as mobile information devices, it is important 
that the client code for communicating with a server be as com- 



pact and efficient as possible, and that traffic between the 
client and server be minimized when requesting services or re- 
sources of the server. This is desirable, because the client's 
resources are generally limited. Some clients have small memory 
capacity and limited graphics capabilities. Other clients may 
need to minimize computation in order to avoid depleting bat- 
tery power, or to improve the responsiveness of an application. 
Furthermore, in the current state of the art, network bandwidth 
limitations and latency can severely limit the utility of thin 
clients . 

[0004] J2EE and J2ME are widely used platform- 

independent technologies, which are used respectively for 
multi-tier enterprise applications and low-end clients, such as 
mobile information devices, smart cards, and mobile telephones. 
The two technologies are not well integrated, and it is not 
convenient or practical for a J2ME client to directly access 
J2EE services on a server. Known solutions designed for 
J2SE/J2EE integration do not scale down to the low processing 
power and network bandwidth of J2ME devices. As a result, de- 
velopers are often compelled to spend a great deal of engineer- 
ing effort developing and debugging protocols for wireless com- 
munication. 

[0005] One widely used protocol for accessing remote 

services is SOAP, which specifies how to encode and transmit 
method invocations and responses using HTTP and XML. SOAP is 
commonly used in conjunction with WSDL, a language for declar- 
ing web services. J2ME clients are currently able to access web 
services using SOAP in several ways. 

[0006] An extensible open-source API, kSOAP, available 

from Enhydra.org, is usable by a MIDP application for accessing 



a subset of SOAP services. This is a solution for MIDlets that 
need to communicate directly with the server , or require flexi- 
bility. However, its memory footprint of 34 Kbytes is currently 
too large for most MIDP devices. 

[0007] Another API , kXML-RPC, is an open-source J2ME 

implementation of the protocol XML-RPC, available from Enhy- 
dra.org. This API is used for cross-platform remote procedure 
calls. XML-RPC is similar to SOAP, but is a more concise proto- 
col . Less network bandwidth and processing power are required 
to transport and parse messages. XML-RPC is less generic, and 
less widely supported than SOAP. 

[0008] A distributed objects framework, YoCOA, is 

available from Yospace, 7, The Courtyard High Street, Staines, 
Middlesex, TW18 4DR, UK. YoCOA is a proprietary set of J2ME and 
J2EE tools and libraries for facilitating end-to-end develop- 
ment. YoCOA provides remote procedure calls to appropriately 
enabled J2EE services. 

[0009] The software product Macrospace Connect, avail- 

able from Macrospace Ltd., 64 Knight sbridge, London, SW1X 7JF, 
UK, is another proprietary set of tools and libraries for fa- 
cilitating end-to-end development. 

[0010] Merely customizing a development tool to work 

optimally with SOAP and WSDL is not a good general solution for 
end-to-end communication, as there are many existing server 
configurations in which the services provided are neither ex- 
pressed in WSDL nor accessed by SOAP. 

[0011] Conventionally, optimization of the client code 

is accomplished by manual code adjustment. This technique is 
cumbersome and labor intensive. Many different optimizations 
may be required for use with different mobile information de- 



vices. Reliance on manual optimization can compel an applica- 
tion developer to dedicate expensive staff to the task of ac- 
commodating new models and types of mobile information device. 
Thus, improving manual optimization techniques would seem to be 
an unpromising approach. 

[0012J It is known to restrict access to software by a 

client by various code obfuscation techniques in order to pre- 
vent reverse -engineering of software, when using languages such 
as Java, which was designed to be compiled into a platform in- 
dependent bytecode format. However, these techniques are of 
limited utility in minimizing an application's code size. 

SUMMARY OF THE INVENTION 

[0013] According to some aspects of the invention, MIDP 

devices employing J2ME technology are enabled to conveniently 
and efficiently access J2EE services that are provided over a 
data network, such as the Internet. The approach taken is to 
use as thin a client as possible, diverting as much processing 
as possible to the server and as much code development as pos- 
sible to an automated tool. 

[0014] In some aspects of the present invention the 

problem of client code optimization is solved by a technique, 
wherein a developer prepares an application for a resource - 
constrained client, such as a mobile information device, in 
which he specifies services to be exported to the client from 
server-side providers. A development tool incorporating a tem- 
plate-driven code generator is invoked to automatically create 
specialized client and server code, optimized for the specified 
services. Use of an optimized protocol allows client code to be 
minimized through elimination of redundant code, and by using 



code optimizations that can be automatically selected by the 
code generator. The server code consists of a mediator that 
acts as a gateway between the client and providers of the 
specified services, translating the optimized protocol into a 
standard protocol that is expected by the providers. The 
server-side providers thus see a conventional client, and need 
not modify their standard procedures in any way in order to re- 
ceive requests from such low-end clients. 

[0015] In some embodiments, the code generator is aware 

of the characteristics of the client, which knowledge is ex- 
ploited for even greater code optimization. For example, the 
code generator may also select from among different implementa- 
tions of a method in order to produce a minimal code size. The 
results are superior to those that could be obtained by an op- 
timizing compiler or code obfuscation engine. 

[0016] An advantage of some aspects of the present in- 

vention is minimization of the computational load on the client 
by automatically and optimally distributing the computation be- 
tween the client and the server. 

[0017] A further advantage of some aspects of the pre- 

sent invention is the reduction of required network bandwidth, 
by providing a specially adapted, concise low-noise protocol to 
be used between the client and the mediator. The mediator re- 
tains the ability to communicate with the service endpoint us- 
ing a conventional protocol. 

[0018] Still another advantage of some aspects of the 

present invention is enhanced system performance and reduced 
client code footprint, when compared with conventional tech- 
niques such as code obfuscation. 



[0019] The invention provides a method of communication 

between a client operating in a first platform- independent en- 
vironment to a server operating in a second platform- 
independent environment in order to obtain a service for the 
client via the server, which is carried out by compiling a pro- 
gram for the client from platform- independent source code, us- 
ing the program to generate a request for the service by the 
client, encoding the request at the client according to a first 
format to define an encoded message, and transmitting the en- 
coded message to a mediator. The method is further carried out 
at the mediator by re-encoding the encoded message into a sec- 
ond format , where in the size of the re-encoded message exceeds 
the size of the encoded message, and transmitting the re- 
encoded message to a provider of the service. 

[0020] According an aspect of the method, the program 

has only the minimum code that is required to produce the first 
format . 

[0021] In still another aspect of the method re- 

encoding the encoded message is performed by decoding the en- 
coded message, and re -encoding the decoded message into the 
second format . 

[0022] According to an additional aspect of the method, 

the request includes a plurality of requests that are assembled 
into an encoded message group in the encoded message. 

[0023] One aspect of the method includes delaying per- 

formance of encoding the request for a latency interval to 
await pendency of additional ones of the plurality of requests. 

[0024] According to a further aspect of the method, the 

plurality of requests are asynchronously initiated. 



[0025] According to another aspect of the method, the 

second format is SOAP. 

[0026] The invention provides a method of establishing 

access by a client to predetermined server-side services, which 
is carried out by installing proxy code in the client to pro- 
vide an interface with an application program executing 
therein, wherein requests for the server-side services are gen- 
erated by the application program, and the proxy code is 
adapted to reformulate the requests as first messages according 
to a first protocol. The method is further carried out by exe- 
cuting a mediator program in a computing device external to the 
client, wherein the mediator program accepts input from the 
client according to the first protocol, and is adapted to re- 
formulate the first messages as second messages according to a 
second protocol. The computing device is capable of communicat- 
ing the second messages to a provider of the server- side ser- 
vices . 

[0027] According to an aspect of the method, the first 

messages are smaller than corresponding second messages. 

[0028] According to still another aspect of the method, 

the first messages each comprise a plurality of requests. 

[0029] In an additional aspect of the method, install- 

ing proxy code includes automatically generating the proxy 
code, substantially without human intervention . 

[0030] In another aspect of the method, generating the 

proxy code is performed according to a predefined template. 

[0031] In one aspect of the method, executing the me- 

diator program includes automatically generating the mediator 
program, substantially without human intervention. 
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[0032] In another aspect of the method, generating the 

mediator program is performed according to a predefined tem- 
plate . 

[0033] According to another aspect of the method, the 

second protocol is SOAP . 

[0034] A further aspect of the method includes install- 

ing an API in the client for access by the application program. 

[0035] According to yet another aspect of the method, 

the proxy code includes a synchronous stub. 

[0036] According to still another aspect of the method, 

the proxy code includes an asynchronous stub. 

[0037] According to an additional aspect of the method, 

the proxy code includes a grouped stub. 

[0038] According to one aspect of the method, the proxy 

code includes instructions for enablement of HTTP for transport 
of the first messages. 

[0039] According to another aspect of the method, the 

proxy code includes instructions for enablement of HTTPS for 
transport of the first messages. 

[0040] According to a further aspect of the method, the 

proxy code includes no more than one procedure for accessing 
the server-side services. 

[0041] According to another aspect of the method, the 

proxy code includes a plurality of Java classes. 

[0042] The invention provides a method of communication 

between a client operating in a first plat form- independent en- 
vironment and a server operating in a second platform- 
independent environment over a data network to obtain a sup- 
ported service for the client via the server, which is carried 
out at the client by encoding a request for the service accord- 



ing to a first format to define an encoded message, and trans- 
mitting the encoded message to a mediator via the data network. 
The method is further carried out at the mediator by re- 
encoding the encoded message into a second format to define a 
re-encoded message, wherein the size of the re-encoded message 
exceeds the size of the encoded message, and transmitting the 
re-encoded message to a provider of the service via the data 
network. 

[0043] The invention provides A computer software prod- 

uct, comprising a computer-readable medium in which computer 
program instructions are stored, which instructions, when read 
by a computer, cause the computer to perform a method for ena- 
bling communication between a client operating in a first plat- 
form-independent environment and a server operating in a second 
platform-independent environment to obtain a service for the 
client via the server, which is carried out at the client by 
encoding a request for the service according to a first format 
to define an encoded message, and transmitting the encoded mes- 
sage to a mediator. The method is further carried out at the 
mediator by re-encoding the encoded message into a second for- 
mat, wherein the size of the re-encoded message exceeds the 
size of the encoded message, and transmitting the re-encoded 
message to a provider of the service. 

[0044] The invention provides a computer software prod- 

uct, including a computer-readable medium in which computer 
program instructions are stored, which instructions, when read 
by a computer, cause the computer to perform a method of estab- 
lishing access by a client operating in a first platform- 
independent environment to a server operating in a second plat- 
form-independent environment to obtain predetermined 



server-side services, which is carried out by generating proxy 
code for installation in the client to provide an interface 
with an application program executing therein, wherein requests 
for the server- side services are generated by the application 
5 program, and the proxy code is adapted to reformulate the re- 
quests as first messages according to a first protocol, and 
generating a mediator program for installation in a computing 
device external to the client. The mediator program accepts in- 
put from the client according to the first protocol, and is 

10 further adapted to reformulate the first messages as second 
messages according to a second protocol. The computing device 
is capable of communicating the second messages to a provider 
of the server-side services. 

[0045] The invention provides a computer software prod- 

15 uct, including a computer- readable medium in which computer 
program instructions are stored, which instructions, when read 
by a computer, cause the computer to perform a method of estab- 
lishing an interaction between a client operating in a first 
plat form- independent environment to a server operating in a 

2 0 second plat form- independent environment over a data network to 
obtain a supported service for the client via the server, which 
is carried out by generating a first program for installation 
in the client, which when executed by the client causes the 
client to encode a request for the service according to a first 

2 5 format to define an encoded message, and to transmit the en- 
coded message to the server via the data network. The method is 
further carried out by generating a second program for instal- 
lation in the server, which when executed by the server causes 
the server to re -encode the encoded message into a second for- 

30 mat, wherein the size of the re-encoded message exceeds the 



size of the encoded message, and to transmit the re-encoded 
message to a provider of the service via the data network. 

[0046] The invention provides a development system for 

establishing access by a client to predetermined server- side 
services, including a computer having a code generator execut- 
ing therein in a first platform- independent environment. The 
code generator is adapted to generate proxy code executable in 
the client to provide an interface with an application program 
executing in the client, wherein requests for the server-side 
services are generated by the application program. The proxy 
code is adapted to reformulate the requests as first messages 
according to a first protocol. The client operates in a second 
plat form- independent environment, and the code generator is 
further adapted to generate a mediator program for a computing 
device external to the client, the mediator program accepting 
input from the client according to the first protocol and being 
further adapted to reformulate the first messages as second 
messages according to a second protocol. The computing device 
is capable of communicating the second messages to a provider 
of the server-side services. 

[0047] According to a further aspect of the development 

system, the code generator is actuated using a command line in- 
terface . 

[0048] According to yet another aspect of the develop- 

ment system, the code generator is linked to an integrated de- 
velopment program. 

[0049] According to still another aspect of the devel- 

opment system, the provider of the server-side services is a 
Java -enabled server. 
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[0050] According to an additional aspect of the devel- 

opment system, the client is a Java-enabled client. 

[0051] According to one aspect of the development sys- 

tem, the mediator program is compiled from Java source code by 
the code generator. 

[0052] According to one aspect of the development sys- 

tem, the first messages are smaller than corresponding ones of 
the second messages. 

[0053] According to an additional aspect of the devel- 

opment system, the first messages each comprise a plurality of 
the requests. 

[0054] According to still another aspect of the devel- 

opment system, an input of the code generator includes a prede- 
fined template. 

[0055] According to another aspect of the development 

system, the template includes Java source code, wherein at 
least a part of the Java source code is copied by the code gen- 
erator to an output file. 

[0056] According to a further aspect of the development 

system, the template also includes a logical directive that 
specifies the part of the Java source code. 

[0057] According to yet another aspect of the develop- 

ment system, the mediator program is generated by the code gen- 
erator responsively to the template. 

[0058] According to a further aspect of the development 

system, the second protocol is SOAP. 

[0059] According to yet another aspect of the develop- 

ment system, the proxy code includes proxy classes. 

[0060] According to another aspect of the development 

system, the proxy code includes a synchronous stub. 



13 

[0061] According to one aspect of the development sys- 

tem, the proxy code includes an asynchronous stub. 

[0062] According to an additional aspect of the devel- 

opment system, the proxy code includes a grouped stub. 

[0063] According to still another aspect of the devel- 

opment system, the proxy code includes instructions for enable- 
ment of HTTP for transport of the first messages. 

[0064] According to yet another aspect of the develop- 

ment system, the proxy code includes instructions for enable- 
ment of HTTPS for transport of the first messages. 

[0065] According to a further aspect of the development 

system, the proxy code includes no more than one procedure for 
accessing the server-side services. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0066] For a better understanding of these and other 

objects of the present invention, reference is made to the de- 
tailed description of the invention, by way of example, which 
is to be read in conjunction with the following drawings, 
wherein: 

[0067] Fig. 1 is a block diagram of a system for pro- 

viding end-to-end communication between a client and a 
server that is constructed and operative in accordance with a 
disclosed embodiment of the invention; 

[0068] Fig. 2 is a block diagram of a system for devel- 

oping specialized client and server software for a MIDP device 
that requires J2EE services in accordance with a disclosed em- 
bodiment of the invention; 



14 

[0069] Fig. 3 is a detailed block diagram of a develop- 

ment tool in the system shown in Fig. 2 in accordance with a 
disclosed embodiment of the invention; 

[0070] Fig. 4 is a flow chart indicating a method of 

preparing specialized software to enable a client to access a 
server to obtain web services in accordance with a disclosed 
embodiment of the invention; and 

[0071] Fig. 5 is a flow chart illustrating a method of 

using an optimized protocol in a client-server end-to-end com- 
munication in accordance with a disclosed embodiment of the in- 
vention. 

DETAILED DESCRIPTION OF THE INVENTION 

[0072] in the following description, numerous specific 

details are set forth in order to provide a thorough under- 
standing of the present invention. It will be apparent to one 
skilled in the art, however, that the present invention may be 
practiced without these specific details. In other instances 
well-known circuits, control logic, and the details of computer 
program instructions for conventional algorithms and processes 
have not been shown in detail in order not to unnecessarily ob- 
scure the present invention. 

[0073] Software programming code, which embodies as- 

pects of the present invention, is typically maintained in per- 
manent storage, such as a computer readable medium. In a cli- 
ent-server environment, such software programming code may be 
stored on a client or a server. The software programming code 
may be embodied on any of a variety of known media for use with 
a data processing system, such as a diskette, or hard drive, or 
CD-ROM. The code may be distributed on such media, or may be 
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distributed to users from the memory or storage of one computer 
system over a network of some type to other computer systems 
for use by users of such other systems. The techniques and 
methods for embodying software program code on physical media 
and distributing software code via networks are well known and 
will not be further discussed herein. 

Architecture. 

[0074] Reference is now made to Fig. 1, which is a 

block diagram of a system 10 for providing end-to-end communi- 
cation between a client and a server that is constructed and 
operative in accordance with a disclosed embodiment of the in- 
vention. A resource -constrained client, operating in a plat- 
form-independent environment designed for small clients, repre- 
sented by a mobile information device 12, is connected to a 
data network 14, which can be the Internet. The mobile informa- 
tion device 12 is typically a J2ME client. An application or 
content server 16 operates in a platform- independent environ- 
ment designed for devices having greater capabilities than the 
mobile information device 12. The server 16 is typically a 
J2EE-enabled server operated by a content provider or a service 
provider, and is connected to the data network 14. A special- 
ized MIDlet 18 executing on the mobile information device 12 
requests desired services or content from the server 16. The 
system 10 includes a gateway server 2 0 that is connected to the 
data network 14. A mediator servlet 22 resides on the 
server 20, and acts as a gateway between the mobile information 
device 12 and the server 16. Thus, unlike conventional data 
network communication, data does not always flow directly be- 
tween the mobile information device 12 and the server 16, as 
will be explained in further detail hereinbelow. Alternatively, 
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the mediator servlet 22 may reside on the server 16 together 
with the server application software. 

[0075] The mediator servlet 22 is typically generated 

by a developer 24, in conjunction with the development of the 
MIDlet 18. In some embodiments the mediator servlet 22, or a 
replica thereof (not shown) , may be accessible to the devel- 
oper 24 via the server 2 0 across the data network 14. Addition- 
ally or alternatively, the developer 24 could access the media- 
tor servlet 22 via a direct link to the server 20. In either 
case, the developer 24 is able, using a development tool 26 in 
the server 20, to optimize the MIDlet 18 according to the par- 
ticular content or services being sought from the server 16, 
and the characteristics of the mobile information device 12. 
Alternatively, the development tool 26 may be located in a dif- 
ferent development machine 28, as indicated by a dotted 
line 30. 

[0076] Reference is now made to Fig. 2, which is a 

block diagram of an arrangement 32 for developing specialized 
client and server software for use by a MIDP device, such as a 
J2ME-enabled mobile information device, that requires J2EE ser- 
vices in accordance with a disclosed embodiment of the inven- 
tion. The disclosure of Fig. 2 should be read in conjunction 
with Fig. 1, in which like elements are given like reference 
numerals. Portions of the arrangement 32 may be incorporated 
within the mediator servlet 22 (Fig. l), or may reside on a 
separate development platform. The arrangement 32 generally 
conforms to a client-server model, in which a client-server di- 
vision is indicated by a vertical line 34. A J2ME client 36 has 
the MIDlet 18 installed therein. The code of the MIDlet 18 is 
typically written by the developer 24 (Fig. 1). An API set 38, 
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consisting of one or more conventional MIDP API's, is installed 
in the client 36. For example, the API set 38 could include the 
J2ME Mobile Media API, which provides audio, video and other 
time-based multimedia support to resource -constrained devices, 
and allows the developer 24 to gain access to native multimedia 
services available on the client 36. 

[0077] J2ME proxy classes 40 are included in the MIDlet 

18 that is installed in the client 36, which enables it to ac- 
cess web services. The proxy classes 4 0 are automatically gen- 
erated by the development tool 26, based on definitions of web 
services and preferences supplied by the developer 24 (Fig. 1) . 
A code generator 42 is provided in the development tool 26. In 
some embodiments, the developer 24 accesses the development 
tool 26 interactively, using a graphical user interface 27. In 
other embodiments, the developer 24 non- interactively submits 
information, for example parameters, to the development 
tool 26. 

[0078] A mediator server 44 is generally indicated on 

the right side of the arrangement 32. The server-side mediator 
servlet 22 interacts with the proxy classes 40 through a cus- 
tomized and optimized protocol 46, optimized for low network 
bandwidth and easy parsing. The mediator servlet 22 is auto- 
matically generated by the development tool 26. The mediator 
servlet 22 interprets web service requests from the client 3 6 
and delivers them to appropriate providers of web ser- 
vices 48, 50 using a standard protocol 52, which can be SOAP, 
or another standard protocol 54. The web services 48, 50 may be 
hosted on the same or a different server as the mediator server 
44. When the mediator servlet 22 receives responses from the 
web services 48, 50, it relays them back to the client 36 using 
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the optimized protocol 46, or a different optimized protocol. 
The web services 48, 50 may be created by the developer 24 
(Fig. l), or by another developer (not shown). 
Proxy Classes. 

[0079] With continued reference to Fig. l and Fig. 2, 

the proxy classes 40 (Fig. 2) contain as simple an interface as 
possible. Thus, from the perspective of the developer 24 
(Fig. 1), developing code using an API provided by a web ser- 
vice is hardly different from developing code using a local 
API. For example, a web service providing the API shown in 
Listing 1 may be represented on the client 36 by the code shown 
in Listing 2. 



Listing 1 

public class HelloService { 

public String sayHello ( String name) { 

return 'Hello " + name + " ! - 

} 

Listing 2 

public class HelloServiceProxy { 

public String sayHello ( String name) throws 

IOException { 

// code to communicate with the service 

// via the mediator 

// and return the result 

} 

[0080] The MIDlet 18 could call the service of List 

ing 2 using a synchronous call, as shown in Listing 3. 

Listing 3 

String server 

http : //www . example . com/services/mediator" ; 
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HelloService service - new HelloServiceProxy (server) ; 
try { 

String greeting = service . sayHello ( "World" ) ; 
} catch (IOException ioe) { 
// exception handling 

Client Agent. 

[0081) Referring again to Fig. 1 and Fig. 2, the cli- 

ent 36 preferably has minimum memory requirements, both in 
terms of static footprint and of heap memory requirements. At 
the present time, in order to be acceptable to developers, it 
is recommended that no more than 15 Kbytes be preempted by the 
client 36. 

15 [0082] There are other general considerations in the 

design of the MIDlet 18 and the proxy classes 40. It is desir- 
able that a minimum amount of processing occurs in the cli- 
ent 36. Since mobile information devices typically have low 
network bandwidth and high latency, the client agent should 
20 generate a minimum amount of network traffic. 

[0083] As noted above, asynchronous calls to web ser- 

vices are supported in the proxy classes 40, and as the HTTP 
protocol is an essential network protocol for MIDP devices, it 
is well supported. The client agent also supports the HTTPS 
protocol, and can be adapted to support all protocols supported 
by MIDP, version 1.0, and is sufficiently flexible to support 
many other any protocols, limited only by the capabilities of 
the client 36. 

Client Protocol. 

30 [0084] with continued reference to Fig. 1 and Fig. 2, 

the optimized protocol 46 used by the proxy classes 40 for com- 
munication with the mediator servlet 22 is configured according 
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to the characteristics of the API set 38. Thus, asynchronous 
requests may be grouped together into a single request to im- 
prove efficiency. This may be achieved by adding an artificial 
latency for example, 100 ma., after a request, during which 
time any additional requests are bundled together with the 
first request. 

Server Protocols. 

[0085] With continued reference to Fig. 1 and Fig. 2, 

the mediator servlet 22 uses SOAP as the standard protocol 52 
for communicating with services, for example the web ser- 
vices 48, which must be SOAP enabled web services. 

[0086] it will be understood that while the web ser- 

vices 48, 50 are shown in Fig. 2, the mediator servlet 22 is 
not limited to communicating with web services, nor to SOAP, or 
even the use of the HTTP protocol. The mediator servlet 22 can 
communicate with many remote services. For those remote ser- 
vices that use non-standard protocols, the developer 24 
(Fig. l) must provide classes (not shown) for communication be- 
tween the mediator servlet 22 and the remote services using the 
remote services' respective protocols. The mediator servlet 22 
calls a developer-provided class in order to effect the commu- 
nication. Although only two standard protocols 52, 54 are il- 
lustrated representatively in Fig. 2, many different standard 
and non-standard protocols can be used in accordance with the 
requirements of different web services. Indeed, virtually all 
non-standard custom protocols can be used, so long as the de- 
veloper 24 (Fig. 1) is aware of their specifications, so that 
an appropriate class can be included in the mediator serv- 
let 22. 



Code Generation Tool. 

[0087] With continued reference to Fig. 1 and Pig. 2, 

the mediator servlet 22 is built automatically by the develop- 
ment tool 26. It acts as a translator between the optimized 
protocol 46 and the standard protocols 52, 54. The code genera- 
tor 42 generates Java source code for the proxy classes 40 and 
the mediator servlet 22. Optionally, the generation of the 
proxy classes 40 and the mediator servlet 22 includes a speci- 
fication of the network transport on which communication oc- 
curs, for example, HTTP, HTTPS , SMS, socket or secure socket. 
The code generator 42 recognizes a directive to generate debug- 
ging classes with tracing statements, and a directive to gener- 
ate optimized classes for deployment as the proxy classes 40. 

[0088] Details of web services are obtained by the de- 

velopment tool 26 in two ways. For web services that are de- 
fined in WSDL, all necessary information can be obtained from 
the WSDL definitions and the location of the web service. For 
other J2EE services, the developer 24 (Fig. l) must provide de- 
tails of the service in the form of a Java interface and the 
name of an implementing class to the development tool 26. 

[0089] The code generator 42 may be implemented using 

the Sun ONE Studio integrated development environment, avail- 
able from Sun Microsystems, Inc. Alternatively, the code gen- 
erator 42 may have a command- line interface, or can be provided 
with a Java API. Alternatively, the code generator 42 can be 
implemented as a stand-alone tool, having its own user inter- 
face . 

[0090] Reference is now made to Fig. 3, which is a de- 

tailed block diagram of the development tool 26 (Fig. 2) in ac- 
cordance with a disclosed embodiment of the invention. The de- 



22 

scription of Fig. 3 should be read in conjunction with Fig. 2, 
in which like elements are given like reference numerals. The 
code generator 42 can be regarded as the core of the develop- 
ment tool 26. it employs code templates 56 in order to create 
the proxy classes 40 and the mediator servlet 22 (Fig. 2) . The 
code generator 42 is accessible via an internal API 58 using a 
command line interface 60 to supply input data 62 that enables 
the code generator 42 to parameterize the code that it pro- 
duces. Alternatively, an integrated development environment 64, 
for example, the Sun ONE Studio, may be linked to the API 58 in 
order to control the code generator 42. 

[0091] The input data 62 supplied to the code genera- 

tor 42, either via the command line interface 60 or the inte- 
grated development environment 64, include the names of classes 
and methods to be exported by the server to the client, details 
of what output files are to be generated, and where they are to 
be placed. The input data 62 further include a feature set that 
is to be supported by the generated client code. Options within 
the feature set include dynamic invocation, synchronous stubs, 
asynchronous stubs, grouped stubs, and enablement of HTTP or 
HTTPS as the underlying network protocol. 

[0092] if the dynamic invocation option is elected, the 

client code includes a single method with a name such as in- 
vokeServerO, which is used to access all functions of the 
server. 

[0093] if the synchronous stubs option is elected, then 

each method exported from the server to the client has a corre- 
sponding method on the client for accessing the server, which 
does not return control to the calling application until the 
call to the server has completed. 
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[0094J If 
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the asynchronous stubs option is elected, 
then each method exported from the server to the client has its 
own method on the client, which calls the server and returns 
control to the calling application immediately. Results from 
the call are retrieved through an interface using the listener 
model . 

[0095] if the grouped stubs option is elected, then 

each method exported from the server to the client has its own 
method on the client. This method prepares a call to the server 
but does not actually call it until yet another method, here 
termed syncGroupO, is called. Using this mechanism, multiple 
calls to methods on the server can be made using a single HTTP 
or HTTPS connection. 

[0096] The code generator 42 loads one or more of the 

code templates 56 in preparation for generating its output. 
Each of the code templates 56 is a blueprint for the code to be 
generated, it contains two interleaved parts, data 66, and 
logic 68. The data 66 consists of Java source code, which is to 
be copied verbatim to output files. The logic 68 is typically 
Java byte code, (e.g., J2ME proxy classes and their infrastruc- 
ture) that is executed during code generation to control what 
parts of the data 66 are to be copied to the mediator serv- 
let 22. For example, the logic 68 in one of the code tem- 
plates 56 may ensure that data 66 that contains code to support 
grouped calls, or to handle receiving arrays of strings from 
the server, is only included if there is an explicit user re- 
quirement for such functionality, or an implicit requirement 
that can be inferred from the configuration data. By appropri- 
ately configuring the data 66 and the logic 68, the code tem- 
plates 56 relieves the developer 24 (Fig. 1) of much of the 
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burden of providing detailed code. Code templates can be pro- 
vided for many different products that can function as the mo- 
bile information device 12 (Fig. 1), Similarly, different code 
templates can be prepared for different web services. As the 
clients and web services encountered today are so diverse, it 
is likely that large catalogs of code templates 56 will be 
maintained for use by the code generator 42. The output of the 
code generator 42, and the optimized protocol 46 (Fig. 2) is 
influenced by the input data 62, in which the developer 24 
(Fig. l) specifies the protocol with which the mediator serv- 
let 22 is to communicate with the remote service. As mentioned 
above, the developer 24 has wide latitude to select a standard 
or a non-standard protocol. 

10097] when the code templates 56 are used to generate 

source code for the client and the server, they are parameter- 
ized with the input data 62 that were supplied via the command 
line interface 60 or the integrated development environment 64. 

[0098] Included in the logic 68 is code that special- 

izes the optimized protocol 46 (Fig. 2) . when the mediator 
servlet 22 on the mediator server 44 receives a call from the 
client 36, it needs to determine which method of the requested 
service is to be invoked. The client 36 sends it an integer 
identification code identifying the requested method. This 
identification code is fixed at the time the proxy classes 4 0 
and the mediator servlet 22 are generated by the development 
tool 26. 

Example 1. 

[0099] This example is presented with continued refer- 

ence to Fig. 2 and Fig. 3. A class StockService on a server of- 
fering the web services 48 has three methods by which particu- 
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lar services can be supplied to the client 36: getStockTick- 
ers(), getStockNameO , and getStockValue ( ) . Each of these three 
methods is assigned a unique integer identification code. When 
the client 36 invokes one of these methods from the web ser- 
vices 48, it transmits a message to the mediator servlet 22 us- 
ing the following 3-part protocol: (1) an integer code indicat- 
ing that a command is about to be sent; (2) the identification 
code integer identifying the requested method; and (3) the pa- 
rameters of the requested method. The 3-part protocol is speci- 
fied by the developer 24 (Fig. 1), who also specifies which 
methods are allowed to be called from the client 36. Any un- 
needed functionality is intentionally omitted from the 3-part 
protocol by the development tool 26 at code generation time. 

[0100] Assume that the client 36 is a stock tracking 

MIDlet. First, it queries the web services 48 to get the list 
of stock tickers for which it can provide data. 

[0101] The client 36 sends a request as shown in List- 

ing 4 to the mediator servlet 22, and waits for a response, 
which it expects to be a list of text strings. The mediator 
servlet 22 receives the request and sends a SOAP request to the 
server hosting the web services 48, as shown in Listing 5. 

Listing 4 

, ( *?"k*5 inte g er > : * (code for a remote service request) 
\H mteger): 1 (one element in this request) 
(32-bit integer): 5 (code for "getStockTickers * ser- 

VI CG ) 



Listing 5 

<?xml version=' 1 . 0' encoding= ' UTF - 8 ' ? > 
<SOAP - ENV : Envelope xmlns : SOAP - ENV='http : 
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/ / schemas . xmlsoap . org/soap/envelope/" 

xmlns : xsi="http : //www . w3 . org/1 999/XMLSchema - 
instance" 

i?i?o : 5SS B, = h 5 tp : //WWW • W3 • ° rg/ 1 999/XMLSchema - > 
<SOAP - ENV : Body> 

etc . 

The mediator servlet 22 receives a SOAP response, as shown in 
Listing 6. 



Listing 6 

<?xml version=' 1 . 0 ' encodings 'UTF- 8 ' '> 
< SOAP - ENV : Envelope 
xmlns: SOAP - 

ENV="http : //schemas . xmlsoap . org/soap/envelope/* 
Xm vmi S n« S1= h h $ZF2 "T," • W3 ' ° rg/1 999/XMLSchema - instance" 

, C l P ; n , f J http : //www ■ w3 • org / 1 999/XMLSchema"> 
<bOAP - ENV : Body> 

etc . 

[0102] The SOAP response contains a list of supported 

stock tickers (say "SUNW", " IBM" and "MSFT" ) , which the media- 
tor servlet 22 relays to the waiting client 36, as shown in 
Listing 7. 

Listing 7 

f?l"SfJ in ^ger): 1 (code for successful operation) 

ln J eger : I < thr ee elements in string array) 
SUNW lnte <?er): 4 (four bytes in first string) 

(32-bit integer): 3 (four bytes in second string) 
^SPT bit inte 9 e r): 4 (four bytes in first string) 

[0103] The client 36 receives this data and then closes 

the connection to the mediator servlet 22. The client 36 now 
wants to get the full business names for the stickers "SUNW" 



and "IBM", it sends a grouped request to the mediator serv- 
let 22, as shown in Listing 8, and waits for a response. 

Listing 8 

quesU lnteger): 1 (code f °r a remote service re- 

(U'm* in teger): 2 (two elements in this request) 

fil'wJ in J eger : J (code for -getStockName- service) 

be sent, 4 (nUmber ° f bytes in strin ^ about to 

SUNW 

(U'm* in * e 9 er > : f (code for "getStockName' service) 

be sent) 9er>: ° f bytSS in String abo ^ to 

IBM 

[0104] The mediator servlet 22 receives this grouped 

request, which in this example is a pair of requests. For each 
request in turn, the mediator servlet 22 composes and sends a 
SOAP request to a remote service to receive the company names 
for the stock ticker, which may be the same or a different ser- 
vice than the web services 48. The mediator servlet 22 then re- 
ceives the SOAP response and extracts critical information. The 
mediator servlet 22 then returns this information to the wait- 
ing client 36, as shown in Listing 9. 

Listing 9 

firiSJ in J e 9 er > : 1 (code for successful operation) 

ray) lntSger) : 22 (twenty-two elements ?„ string ar- 
Sun Microsystems, Inc. 

HI'm* in 5 eger ! 1 (code f or successful operation) 
ray) integer) : 44 <*>rty-four element/ in string ar- 

International Business Machines Corporation 
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[0105] The client 36 receives the response shown in 

Listing 9, and disconnects from the mediator servlet 22. 
Client Code Size Reduction. 

[0106] As shown in Example 1, and with continued refer- 

ence to Fig. 2 and Fig. 3, the code generator 42 is constructed 
to exclude unused and unneeded code from the proxy classes 40 
and the mediator servlet 22. The logic 68 in the code tem- 
plates 56 (Fig. 3) ensures that only code for required features 
and data types is generated by the code generator 42 . For exam- 
ple, if no Boolean value is ever returned by the web ser- 
vices 48, 50, the client 36 is not provided any code for deal- 
ing with Boolean return values . 

Client Code Optimization. 

[0107] Continuing to refer to Fig. 2 and Fig. 3, in ad- 

dition to simply not generating code for unneeded features, the 
code generator 42 can apply other optimizations based on its 
intimate knowledge of the exact requirements specified by the 
developer 24 (Fig. 1). The following optimizations are exam- 
ples. 

[0108] The code generator 42 may generate inline code 

for methods that are used only once or twice, and generate in- 
vokable method code for methods that are called more fre- 
quently. 

[0109] The code generator 42 may evaluate more than one 

algorithm for the client source code, and employ the one most 
appropriate to the balance of stub methods that are generated, 
in accordance with the logic 68 in the code templates 56. For 
example, if there are only a few synchronous stubs to be gener- 
ated, then the logic 68 may recognize that code space can be 



conserved by generating stub code that writes directly to a 
HTTP or HTTPS output stream, instead of using a default generic 
mechanism. 

Operation. 

[0110] Reference is now made to Fig. 4, which is a flow 

chart indicating a method of preparing specialized software to 
enable a client to access a server to obtain remote services in 
accordance with a disclosed embodiment of the invention. The 
process begins at initial step 70, wherein software specifica- 
tions are prepared. Here a developer specifies which remote 
services are intended to be accessed by the client. 

[0111] Next, at step 72, input data, typically parame- 

ters, are introduced at this time, for use by the code tem- 
plates as parameters during code generation. A development tool 
is typically employed at this step, as disclosed hereinabove. 
Code templates appropriate to the particular client and most 
closely adapted to the desired remote services are automati- 
cally selected and loaded by a code generator. 

10112] Next, at step 74, proxy classes are generated by 

the developer, using a development tool. Included in the proxy 
classes are classes having methods that invoke desired remote 
services. The methods encrypt requests for remote services into 
a form that is more compact than requests produced by the API's 
that were installed in step 74. One or more of such requests is 
then incorporated into a transmission package in accordance 
with a specified optimized protocol. Other methods deal with 
receipt of encoded data and their decoding into conventional 
data formats. 

[0113] Next, at step 76 a MlDlet is encoded by the de- 

veloper, and installed in the client. The MIDlet is dependent 
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on the proxy classes, which were generated at step 74. Typi- 
cally, an emulator is used to develop the MIDlet . The remote 
services to be accessed by the MIDlet correspond to the remote 
services that are dealt with by the code templates that were 
selected at step 72. Typically, the MIDlet code employs calls 
made available by the API's that were installed in step 74. 

[0114] Next, at step 78 a mediator servlet is generated 

and installed on a server. The mediator servlet is configured 
to use the optimized protocol, and to translate encrypted in- 
formation into invocations of requested remote services using a 
standard protocol, for example SOAP. The mediator servlet is 
also constructed to perform an inverse operation, wherein re- 
sults received as a result of requests for remote services are 
encrypted into the same or a different optimized protocol for 
retransmission to the client. 

[0115] At final step 82 network connections are estab- 

lished, and the client -server system can be placed into opera- 
tion. 

[0116] Reference is now made to Fig. 5, which is a flow 

chart illustrating a method of using an optimized protocol in 
client-server end-to-end communication in accordance with a 
disclosed embodiment of the invention. The process begins at 
initial step 84, where a client and a server are configured us- 
ing the procedure set forth in Fig. 4. The process steps are 
shown in a particular sequence in Fig. 5 for clarity of presen- 
tation. However, it will be evident that many of them can be 
performed in parallel, asynchronously, or in different orders. 

[0117] Next, at step 86, a client request for a remote 

service is now formulated, and encoded according to the opti- 
mized protocol. Typically, an identification code is assigned 



to each allowable service and substituted for the conventional 
service identification. The parameter list of the individual 
services may also be encoded in a compressed format. 

£0118] Control now passes to step 88, where the encoded 

information is transmitted from the client to the server. 

[0119] Next, at step 90 at the server an encoded mes- 

sage is decoded. A remote service request is identified, to- 
gether with any parameters. The request is reformulated in ac- 
cordance with a standard protocol, for example SOAP. 

[0120] Next, at step 92, the remote service identified 

in step 90 is accessed by the server using the standard proto- 
col. The remote service may be provided on the same server as 
decoded the message, or on a different server. 

[0121] Control now passes to decision step 94, where it 

is determined if there are more service requests to be encoded. 
If the determination at decision step 94 is affirmative, then 
control returns to step 90. 

[0122] if the determination at decision step 94 is 

negative, then the results of the service requests submitted in 
step 92 are awaited and processed. Control proceeds to step 96, 
where all currently received results are encoded according to 
the optimized protocol. Typically, the identification code as- 
signed to a particular service is substituted for the conven- 
tional service identification. The results obtained from each 
of the individual services are also encoded in compressed for- 
mat . 

[0123] Control proceeds to step 98, where the encoded 
information is transmitted from the server to the client. 
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[0124] Next, at step 100 at the client an encoded mes- 

sage is decoded. A remote service is identified in the message, 
together with the accompanying results. 

C0125] Next, at step 102, the results that were decoded 

at step 100 are processed by client software. For example, they 
may be formatted and visually displayed. 

[0126] Control now passes to decision step 104, where 

it is determined if there are more service requests to be en- 
coded. If the determination at decision step 104 is affirma- 
tive, then control returns to step 100. 

[0127] if the determination at decision step 104 is 

negative, then control proceeds to final step 106, and the 
process terminates. 

[0128] it will be appreciated by persons skilled in the 

art that the present invention is not limited to what has been 
particularly shown and described hereinabove. Rather, the scope 
of the present invention includes both combinations and sub- 
combinations of the various features described hereinabove, as 
well as variations and modifications thereof that are not in 
the prior art, which would occur to persons skilled in the art 
upon reading the foregoing description. 
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Claims : 



1. A method of communication between a client operating in 
a first plat form- independent environment to a server operating 
in a second platform- independent environment to obtain a ser- 
vice for said client via said server, comprising the steps of: 

compiling a program for said client from a platform- 
independent source code; 

using said program to generate a request for said service 
by said client; 

at said client encoding said request according to a first 

format to define an encoded message- 
transmitting said encoded message to a mediator; 
at said mediator re-encoding said encoded message into a 

second format to define a re-encoded message, wherein a size of 

said re-encoded message exceeds a size of said encoded message; 

and 

transmitting said re-encoded message to a provider of said 
service. 

2. The method according to claim 1, wherein said program 
has only a minimum code that is required to produce said first 
format . 

3. The method according to claim 1 or 2, wherein said step 
of re-encoding said encoded message is performed by decoding 
said encoded message to define a decoded message, and re- 
encoding said decoded message into said second format. 
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4. The method according to any of claims 1-3, wherein said 
request comprises a plurality of requests that are assembled 
into an encoded message group in said encoded message. 

5. The method according to claim 4, further comprising the 
step of delaying performance of said step of encoding said re- 
quest for a latency interval to await pendency of additional 
ones of said plurality of requests. 

6. The method according to claim 4, wherein said plurality 
of requests are asynchronously initiated. 

7. The method according to any of the preceding claims, 
wherein said second format is SOAP . 

8. A method of establishing access by a client to predeter- 
mined server-side services, comprising the steps of: 

installing proxy code in said client to provide an inter- 
face with an application program executing therein, wherein re- 
quests for said server-side services are generated by said ap- 
plication program and said proxy code is adapted to reformulate 
said requests as first messages according to a first protocol; 
and 

executing a mediator program in a computing device external 
to said client, said mediator program accepting input from said 
client according to said first protocol and being further 
adapted to reformulate said first messages as second messages 
according to a second protocol, said computing device being ca- 
pable of communicating said second messages to a provider of 
said server-side services. 
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9. The method according to claim 8, wherein said first mes- 
sages are smaller than corresponding ones of said second mes- 
sages . 

10. The method according to claim 8 or 9, wherein said 
first messages each comprise a plurality of said requests. 

11. The method according to any of claims 8-10, wherein 
said step of installing proxy code comprises automatically gen- 
erating said proxy code substantially without human interven- 
tion. 

12. The method according to claim 11, wherein said step of 
generating said proxy code is performed according to a prede- 
fined template. 

13. The method according to any of claims 8-12, wherein 
said step of executing a mediator program comprises automati- 
cally generating said mediator program substantially without 
human intervention. 

14. The method according to claim 13, wherein said step of 
generating said mediator program is performed according to a 
predefined template. 

15. The method according to any of claims 8-14, wherein 
said second protocol is SOAP. 
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16. The method according to any of claims 8-15, further 
comprising the step of installing an API in said client for ac- 
cess by said application program. 

17. The method according to any of claims 8-16, wherein 
said proxy code comprises a synchronous stub. 

18. The method according to any of claims 8-16, wherein 
said proxy code comprises an asynchronous stub. 

19. The method according to any of claims 8-16, wherein 
said proxy code comprises a grouped stub. 

20. The method according to any of claims 8-19, wherein 
said proxy code comprises instructions for enablement of HTTP 
for transport of said first messages. 

21. The method according to any of claims 8-19, wherein 
said proxy code comprises instructions for enablement of HTTPS 
for transport of said first messages. 

22. The method according to any of claims 8-21, wherein 
said proxy code comprises no more than one procedure for ac- 
cessing said server-side services. 



!3. The method according to any of claims 8-22, wherein 
proxy code comprises a plurality of Java classes. 
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24. A method of communication between a client operating in 
a first platform- independent environment and a server operating 
in a second plat form- independent environment over a data net- 
work to obtain a supported service for said client via said 
5 server, comprising the steps of: 

at said client encoding a request for said service accord- 
ing to a first format to define an encoded message; 

transmitting said encoded message to a mediator via said 
9 data network; 

10 at said mediator re-encoding said encoded message into a 

11 second format to define a re-encoded message, wherein a size of 

12 said re-encoded message exceeds a size of said encoded message; 

13 and 

14 transmitting said re -encoded message to a provider of said 

15 service via said data network. 
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25. The method according to claim 24, wherein said step of 
re -encoding said encoded message is performed by decoding said 
encoded message to define a decoded message; and re-encoding 
said decoded message into said second format. 

26. The method according to claim 24 or 25, wherein said 
request comprises a plurality of requests that are assembled 
into an encoded message group in said encoded message. 

27. The method according to claim 26, further comprising 
the step of delaying performance of said step of encoding a re- 
quest for a latency interval to await pendency of additional 
ones of said plurality of requests. 
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28. The method according to claim 26, wherein said plural- 
ity of requests are asynchronously initiated. 

29. The method according to any of claims 24-28, wherein 
said second format is SOAP. 



30. A computer software product, comprising a computer- 
readable medium in which computer program instructions are 
stored, which instructions, when read by a computer, cause the 
computer to perform a method of communication between a client 
operating in a first plat form- independent environment and a 
server operating in a second plat form- independent environment 
to obtain a service for said client via said server, comprising 
the steps of: 

at said client encoding a request for said service accord- 
ing to a first format to define an encoded message; 

transmitting said encoded message to a mediator; 

at said mediator re-encoding said encoded message into a 
second format to define a re-encoded message, wherein a size of 
said re-encoded message exceeds a size of said encoded message; 
and 

transmitting said re-encoded message to a provider of said 
service . 

31. The computer software product according to claim 30, 
wherein said step of re-encoding said encoded message is per- 
formed by decoding said encoded message to define a decoded 
message; and re -encoding said decoded message into said second 
format . 



32. The computer software product according to claim 30 or 
31, wherein said request comprises a plurality of requests that 
are assembled into an encoded message group in said encoded 
message. 

33. The computer software product according to claim 32, 
wherein said computer is further instructed to delay perform- 
ance of said step of encoding a request for a latency interval 
to await pendency of additional ones of said plurality of re- 
quests . 

34. The computer software product according to claim 32 , 
wherein said plurality of requests are asynchronously initi- 
ated. 

35. The computer software product according to any of 
claims 30-34, wherein said second format is SOAP. 

36. A computer software product, comprising a computer- 
readable medium in which computer program instructions are 
stored, which instructions, when read by a computer, cause the 
computer to perform a method of establishing access by a client 
operating in a first platform- independent environment to a 
server operating in a second platform- independent environment 
to obtain predetermined server-side services, comprising the 
steps of: 

generating proxy code for installation in said client to 
provide an interface with an application program executing 
therein, wherein requests for said server-side services are 
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12 generated by said application program and said proxy code is 

13 adapted to reformulate said requests as first messages accord- 

14 ing to a first protocol; and 

15 generating a mediator program for installation in a comput- 

16 ing device external to said client, said mediator program ac- 

17 cepting input from said client according to said first protocol 

18 and being further adapted to reformulate said first messages as 

19 second messages according to a second protocol, said computing 
2 0 device being capable of communicating said second messages to a 
21 provider of said server- side services. 

1 37. The computer software product according to claim 36, 

2 wherein said application program has only a minimum protocol 

3 generation code that is required to produce said first messages 

4 in said first protocol. 

1 38. The computer software product according to claim 36 or 

2 37, wherein said first messages are smaller than corresponding 

3 ones of said second messages . 

1 39. The computer software product according to any of 

2 claims 36-38, wherein said first messages each comprise a 

3 plurality of said requests. 



1 

2 
3 



40. The computer software product according to any of 
claims 36-3 9, wherein said step of generating proxy code is 
performed substantially without human intervention. 



1 

2 



1 

2 



41. The computer software product according to claim 40, 
wherein said step of generating proxy code is performed accord- 
ing to a predefined template. 



1 42 
2 



The computer software product according to any of 
claims 36-41, wherein said step of generating a mediator pro- 
gram is performed substantially without human intervention. 

43. The computer software product according to claim 42 
wherein said step of generating a mediator program is performed 
according to a predefined template. 

44. The computer software product according to any of 
claims 36-43, wherein said second protocol is SOAP. 

45. The computer software product according to any of 
claims 36-44, further comprising the step of installing an API 
in said client for access by said application program. 

46. The computer software product according to any of 
claims 36-45, wherein said proxy code comprises a synchronous 
stub. 



47. The computer software product according to any of 
claxms 36-45, wherein said proxy code comprises an asynchronous 



stub 



48. The computer software product according to any of 
claims 36-45, wherein said proxy code comprises a grouped stub. 
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The computer software product according to any of 
claims 36-48, wherein said proxy code comprises instructions 
for enablement of HTTP for transport of said first messages. 

50. The computer software product according to any of 
claims 36-48, wherein said proxy code comprises instructions 
for enablement of HTTPS for transport of said first messages. 

51. The computer software product according to any of 
claims 36-50, wherein said proxy code comprises no more than 
one procedure for accessing said server-side services. 

52. The computer software product according to any of 
claims 36-51, wherein said proxy code comprises a plurality of 
Java classes. 



53. A computer software product, comprising a computer- 
readable medium in which computer program instructions are 
stored, which instructions, when read by a computer, cause the 
computer to perform a method of establishing an interaction be- 
tween a client operating in a first platform- independent envi- 
ronment to a server operating in a second plat form- independent 
environment over a data network to obtain a supported service 
for said client via said server, comprising the steps of: 

generating a first program for installation in said client, 
which when executed by said client causes said client to per- 
form the steps of : 

encoding a request for said service according to a 
first format to define an encoded message; and 



16 
17 
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14 transmitting said encoded message to said server via 

15 said data network; and 

generating a second program for installation in said 
server, which when executed by said server causes said server 
18 to perform the steps of: 

re -encoding said encoded message into a second format 
to define a re-encoded message, wherein a size of said re- 
encoded message exceeds a size of said encoded message; and 
transmitting said re-encoded message to a provider of 
said service via said data network. 



19 
20 
21 
22 
23 
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54. The computer software product according to claim 53, 
wherein said step of re-encoding said encoded message is per- 
formed by decoding said encoded message to define a decoded 
message; and re-encoding said decoded message into said second 
5 format . 



1 

2 
3 
4 

1 
2 
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4 



55. The computer software product according to claim 53 or 
54, wherein said request comprises a plurality of requests that 
are assembled into an encoded message group in said encoded 
message . 

56. The computer software product according to claim 55, 
wherein said client is further instructed to delay performance 
of said step of encoding a request for a latency interval to 
await pendency of additional ones of said plurality of re- 



5 quests 
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57. The computer software product according to claim 55 , 
wherein said plurality of requests are asynchronously initi- 
ated. 

58. The computer software product according to any of 
claims 53-57, wherein said second format is SOAP. 

59. A development system for establishing access by a cli- 
ent to predetermined server- side services, comprising: 

a computer having a code generator executing therein within 
a first plat form- independent environment, said code generator 
being adapted to generate proxy code executable in said client 
to provide an interface with an application program executing 
in said client, wherein requests for said server-side services 
are generated by said application program and said proxy code 
is adapted to reformulate said requests as first messages ac- 
cording to a first protocol, wherein said client operates in a 
second platform- independent environment; and 

said code generator being further adapted to generate a me- 
diator program for a computing device external to said client, 
said mediator program accepting input from said client accord- 
ing to said first protocol and being further adapted to refor- 
mulate said first messages as second messages according to a 
second protocol, said computing device being capable of commu- 
nicating said second messages to a provider of said server-side 
services . 

60. The development system according to claim 59, wherein 
said code generator is actuated using a command line interface. 
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61. The development system according to claim 59 or 60, 
wherein said code generator is linked to an integrated develop- 
ment program. 

62. The development system according to any of claims 59- 
61, wherein said provider of said server-side services is a 
Java-enabled server. 

63. The development system according to claim 62, wherein 
said client is a Java-enabled client. 

64. The development system according to any of claims 59- 

63, wherein said mediator program is compiled from Java source 
code by said code generator. 

65. The development system according to any of claims 59- 

64, wherein said first messages are smaller than corresponding 
ones of said second messages . 

66. The development system according to any of claims 59- 

65, wherein said first messages each comprise a plurality of 
said requests. 

67. The development system according to any of claims 59- 

66, wherein an input of said code generator comprises a prede- 
fined template. 
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68. The development system according to claim 67, wherein 
said template comprises Java source code, wherein at least a 
part of said Java source code is copied by said code generator 
to an output file. 

69. The development system according to claim 68, wherein 
said template further comprises a logical directive that speci- 
fies said part of said Java source code. 

70. The development system according to claim 68, wherein 
said mediator program is generated by said code generator re- 
sponsively to said template. 

71. The development system according to any of claims 59- 

70, wherein said second protocol is SOAP. 

72. The development system according to any of claims 59- 

71, wherein said proxy code comprises proxy classes. 

73. The development system according to any of claims 59- 

72, wherein said proxy code comprises a synchronous stub. 

74. The development system according to any of claims 59- 
72, wherein said proxy code comprises an asynchronous stub. 



75. The development system according to any of claims 59- 
, wherein said proxy code comprises a grouped stub. 



76. The development system according to clany of claims 59 
75, wherein said proxy code comprises instructions for enable 
ment of HTTP for transport of said first messages. 

77. The development system according to any of claims 59 
75, wherein said proxy code comprises instructions for enable 
ment of HTTPS for transport of said first messages. 

78. The development system according to any of claims 59- 
77, wherein said proxy code comprises no more than one proce 
dure for accessing said server-side services. 
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